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Beschreibung 

Verfahren zum Betreiben eines Kurzstrecken-Funksende-/- 
Funkempf angs systems gemaS einem Kurzstreckenfunkkommunikati- 
5 onsstandard und Master-Gerat zur Durchfuhrung des Verfahrens 

Die Erf indung betrif f t ein Verfahren zum Betreiben eines 
Kurzstrecken-Funksende-/-Funkempfangssystems gemaS einem 
Kurzstreckenfunkkommunikationsstandard gemafi dem Oberbegriff 
* 10 des Anspruchs 1 und ein Master-Gerat zur Durchftihrung des 
Verfahrens gemafi dem Oberbegriff des Anspruchs 7. 

^^^^ Der "Bluetooth-Standard" ist ein Kurzstreckenf unkstandard, 

der mit TrSgerf requenzen aus dem weltweit nicht lizenzierten 

15 "Industrial-" , "Scientific-", "Medical" 2,4 GHz Band (ISM- 

Band) funktioniert und eine drahtlose Verbindung von Endgera- 
ten (Devices) in einer Funkzelle mit einem Radius bis zu 10 
Metern, in besonderen Fallen sogar bis uber 100 Metern, er- 
mSglicht, wobei die Tragerf requenzen, um Funkinterf erenzen zu 

20 verhindern, in einer (pseudo-) zuf alligen Reihenfolge bis 

1600mal pro Sekunde gewechselt werden. Fur dieses Frequenz- 
sprungverfahren "Frequency Hopping" sind bis zu 79 Frequenzen 
(Kanale) im Bereich zwischen 2,402 und 2,480 GHz vorgesehen. 

■ m Bis zu acht nach dem Bluetooth-Standard funktionierende Gera- 
te, auch als Devices bezeichnet, konnen in der - auch als 
j, "Pico-Zelle" bezeichneten - Funkzelle zu einem sogenannten 

"Pico-Netz" zusammengeschlossen werden und miteinander kommu- 
nizieren, wobei die einzelnen Devices - durch Zeitmultiplex- 
30 verfahren realisiert - Mitglieder mehrerer Pico-Netze sein 

konnen, so dass diese Pico-Netze dadurch zu einem sogenannten 
"Scatter-Netz" verbunden sind. 

Jedes Device in einem Pico-Netz, kann dieses Pico-Netz initi- 
35 alisieren. Ein Device, das ein Pico-Netz initialisiert hat, 
kontrolliert die restlichen Mitglieder des Pico-Netzes und 
synchronisiert deren Timer, daher wird es mit "Master" (Gera- 
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te-Master) bezeichnet, wahrend die verbleibenden Mitglieder 
des Pico-Netzes mit "Slaves" bezeichnet werden. 
Devices, die Mitglieder mehrerer Pico-Netze sind und diese 
Pico-Net ze, die sich durch unterschiedliche Hopping-Kanal 
5 Folgen unterscheiden lassen, zu Scatter-Netzen vereinen, syn- 
chronisieren sich in jedem Multiplex-Zeitschlitz auf den je- 
weils aktuellen Master auf. 

Bevor sie eine Verbindung im Pico-Netz aufbauen, befinden 
10 sich Bluetooth Gerate in einem Stromsparmodus "Standby- 
Modus". Dieser Standby-Modus ist kein Stromsparmodus im Blue- 
tooth-Sinn. Vielmehr hat dieser Modus die Bedeutung, dass das 
Gerat initialisiert und bereit ist, Verbindungen aufzubauen 
oder anzunehmen. Dementsprechend gibt es in diesem Zustand 
15 auch kein zyklisches Suchen nach Nachrichten im Netz, da zu 

diesem Zeitpunkt noch kein Netz vorhanden ist. Allenfalls auf 
eine Geratesuche (Inquiry) wird geantwortet. Dieser Prozess 
wird jedoch von einem anderen Gerat (Remote-Device) angesto- 
Sen und unterliegt deswegen keinem zeitlichen Schema. 

20 

Neben dem Standby-Modus ohne Netzverbindung ist noch eine* 
Reihe weiterer Stromsparf unktionen moglich. Im "Hold-Modus" 
bleibt das Gerat in das Pico-Netz integriert, es werden aber 
keine Daten iibertragen. Lediglich ein interner Timer lauft im 
25 Slave weiter. Bei Bedarf startet die Datenubertragung verzo- 
gerungsfrei. Der Hold-Modus kann vom Master fur den Slave an- 
geordnet werden. Anderseits kann der Slave den Master auffor- 
dern, ihn in diesen Modus zu schalten. 

3 0 Im "Sniff -Modus" lauscht das Gerat in programmierbaren Ab- ' 
standen in das Netz. Auch hier lauft der Timer zur Synchroni- 
sation im Slave weiter. 

Weiterhin lassen sich Gerate im Netz parken ("Park-Modus"). 
35 Hierbei verliert das Gerat seine Adresse im Netz, kann den 

Netzverkehr also nur mehr mit verfolgen und synchronisiert in 
groSeren Abstanden seinen internen Timer mit dem des Masters. 
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Nachteilig ist, dass ein Master-Gerat gemaS beispielsweise 
dem Bluetooth- Standard nur mit maximal 7 weiteren Geraten 
kommunizieren kann. 

Aufgabe der vorliegenden Erfindung ist, ein Verfahren und ein 
Master-Gerat anzugeben, mit denen die durch einen Standard 
wie zum Beispiel den Bluetooth-Standard festgelegte maximale 
Anzahl miteinander kommunizieren konnender Gerate aufgebro- 
chen wird. 

Diese Aufgabe wird bezuglich des Verfahrens ausgehend von ei- 
nem Verfahren der eingangs genannten Art erf indungsgemaS 
durch ein Verfahren gelost, das die im kennzeichnenden Teil 
des Anspruchs 1 angegebenen Verf ahrensschritt aufweist. Be- 
zuglich des Master-GerSts wird diese Aufgabe erf indungsgemaS 
durch ein Master-Gerat gelost, das die Merkmale des Anspruchs 
7 aufweist. 

Bezuglich des Verfahrens werden die Anzahl von Geraten, die 
gemafi einem vorliegenden Standard die Anzahl der oberen Gren- 
ze miteinander kommunizieren konnender Gerate ubersteigt, in 
einen Park-Modus geschaltet und werden die in den Park-Modus 
geschalteten Gerate fortlaufend nach einer vorgegebenen Stra- 
tegie aktiv und aktive Gerate geparkt geschaltet. 

Bezuglich des Master-Gerates weist das Master-Gerat einen Ge- 
rate-Manager auf , der das oben beschriebene erf indungsgemafie 
Verfahren in entsprechender Weise steuert. 

Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand 
von Unteranspruchen . 

Danach wird gegenuber der Mindestanzahl von in den Park-Modus 
zu schaltender Gerate zusatzlich noch mindestens ein einziges 
weiteres Gerat in den Park-Modus geschaltet. Das hat den Vor- 
teil, dass schnell ein Gerat in den Aktiv-Modus geschaltet 
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werden kann und nicht erst ein anderes Gerat in den Park- 
Modus geschaltet werden muss. Dadurch ist ein beschleunigter 
Verfahrensablauf sichergestellt . 

5 Wird far das Schalten in den Aktiv-Modus von geparkten Gera- 
ten die Strategie verwendet, in Zeitscheiben vorzugehen, hat 
das den Vorteil, dass keines der geparkten Gerate zu lange 
warten muss, bis es an die Reihe kommt . 

10 wird fur das Schalten in den Aktiv-Modus von geparkten Gera- 
ten die Strategie verwendet, Priori tatskriterien zu beriick- 
sichtigen, hat das den Vorteil, dass hotter priorisierte Vor- 
gSnge schneller zum Abarbeiten kommen. 

15 wird fur das Schalten in den Aktiv-Modus von geparkten Gera- 
ten eine Mischstrategie aus den oben beschriebenen Strategien 
verwendet, fuhrt dies zu einer zusatzlichen Optimierung des 
gesamten Ablaufs. 

20 Eine MQglichkeit der Berticksichtigung von Prioritatskriterien 
ist, die Datenraten der Gerate zu analysieren und entspre- 
chend zu berucksichtigen. 

Nachfolgend wird ein Ausfiihrungsbeispiel der Erfindung an 
25 Hand einer Zeichnung naher erlautert. Darin zeigen: 

Pigur 1 eine schematische Darstellung eines Protokoll- 

Stacks mit erf indungsgemafiem Zusatz, und 
Pigur 2 eine schematische Darstellung des Ablaufs des er- 
30 findungsgemaSen Verfahrens. 

In der Figur 1 sind Funktionseinheiten von einem das erfin- 
dungsgemafie Verfahren ausfuhrenden "Protocol Stack" (Stack) 
SURFBLUE dargestellt, wobei allgemein unter einem "Protocol 
35 Stack" eine Pro tokoll software verstanden wird fur benachbar- 
te, in Abhangigkeit stehende Schichten des OSI Referenzmo- 
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dells, die funktional zusammengehSren. Sie dient im Allgemei- 
nen der Implementierung spezieller Netzwerkarchitekturen. 

Die Architektur des dargestellten Stacks SURFBLUE ist in ei- 
nem ein Bluetoothmodul aufnehmenden Wirt HOST implementiert 
und kommuniziert mit anderen Schichten (Applikations- und 
Transport schicht) bzw. ihnen zugeordneten Einheiten BT- 
APPLIKATION , DRIVER, TRANS PORT -LAYER tiber eine hierfur vorge- 
sehene externe Schnittstelle 1. 

Der Stack SURFBLUE weist mehrere Protokolle auf . Eines gemaS 
Bluetooth Standard vorgegebene Protokoll (Core Protocol) , ist 
das "Logical Link Control and Adaptation Protocol" L2CAP, 
welches fur aufsetzbare Protokolle verbindungsorientierte und 
verbindungslose (loopback) Verbindungen fur hohere Protokoll- 
schichten. 

Das logische Verbindungskontroll- und Anpassungs-Protokoll 
L2CAP weist uber eine interne Schnittstelle 2 Verbindung zu 
einer Telef onkontroll-Protokoll-Spezif ikation ( "Telephony 
Control protocol Specification") TCS auf. Die Telef on- 
kontroll-Protokoll-Spezif ikation TCS umfasst im Allgemeinen 
zum einen ein bitorientiertes Protokoll, dass eine Rufkon- 
trolle, Verbindungsaufbau, Sprachubertragung sowie Datenuber- 
tragung realisiert, und zum anderen setzt es AT-Befehle f\ir 
Handys und Modems, zu deren Steuerung Oder fur eine Art FAX - 
Ubertragung ab. 

Das logische Verbindungskontroll- und Anpassungsprotokoll 
30 L2CAP ist uber die interne Schnittstelle 2 zudem mit einem 

seriellen Kabelemulationsprotokoll RFCOMM verbunden, welches 
gemafc ETSI ZS 07.10 definiert ist und oberhalb des logischen 
Verbindungskontroll- und Anpassungsprotokolls L2CAP zur Emu- 
lation einer RS232 Verbindung wie ETSI TS 07.10 bei GSM, z.B. 
35 zur direkten Steuerung uber AT Kommandos, dient. 
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Des weiteren weist das logische Verbindungskontroll- und An- 
passungsprotokoll L2CAP uber die interne Schnittstelle 2 eine 
Verbindung zu einem Lokalisierungs-Protokoll (Service Disco- 
very Protocol) SDP auf , welches fur die Lokalisierung der von 
5 Bluetooth-Geraten in Funkreichweite angebotenen Dienste zu- 
standig ist und seinerseits iiber die interne Schnittstelle 2 
mit der Anpassungsschicht ADAPTION des OSI Ref erenzmodells 
kommuniziert . 

10 Das logische Verbindungskontroll- und Anpassungsprotokoll 

L2CAP kommuniziert daruber hinaus auch mit einer Wirtrechner- 
Kontroller-Schnittstelle (Host Controller Interface) HCI, 
welche notwendig ist, wenn ein Bluetooth Gerat uber den Wirt 
HOST gesteuert wird. 



15 



20 



25 



30 



35 



Zu diesem Zweck kommuniziert die Wirtrechner-Kontroller- 
Schnittstelle HCI mit einer Vielzahl der beschriebenen Proto- 
kolle und Schichten, wie beispielsweise der Anpassungsschicht 
ADAPTION - iiber die interne Schnittstelle 2 - oder der Trans- 
portschicht TRANSPORT-LAYER - uber die exteme Schnittstelle 



1 



Zur Umsetzung eines Prozessmanagements bzw. zum Betrieb des 
Stacks SURFBLUE weist der Stack SURFBLUE einige weitere Mo- 
dule auf, wie zum Beispiel das Modul zur Umsetzung von si- 
cherheitsrelevanten Prozessen SECURITY -MANAGEMENT , welches 
iiber die interne Schnittstelle hierzu zumindest mit dem logi- 
schen Verbindungskontroll- und Anpassungsprotokoll L2CAP, dem 
Lokalisierungsprotokoll SDP sowie der Wirtrechner-Kontroller- 
Schnittstelle HCI verbunden ist, das Modul zur Umsetzung ei- 
nes Geratemanagements (Device Interface management) DI- 
MANAGEMENT sowie ein Modul fur die Umsetzung eines Empfangs- 
/Sendepuffer Managements RX/TX-BUFFER-MANAGEMENT. 

Daruber hinaus weist das Protokollstack SURFBLUE eine Ener- 
giesparsteuereinrichtung POWER- SAVE-MANAGER und zur Umsetzung 
des erfindungsgemaSen Verfahrens einen Gerate-Manager DEVICE 



V 
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MANAGER auf , die zumindest mit der Anpassungsschicht ADAPTION 
uber eine eigene Anpassungsschicht-Powermanagement Schnitt- 
stelle 3 -and der wirtrechner-Kontroller-Schni.ttstelle uber 
eine wirtrechner-Kontroller--Schnittstelle-Powermanagement- 
5 schnittstelle HCI zur Umsetzung des in der Figur 2 gezeigten 
Ausfuhrungsbeispiels des erf indungsgemaSen Verfahrens verbun- 
den ist. 

In Bezug auf die Figur 2 sind zur Vereinf achung des Sachver- 
10 halts folgende MaSgaben beriicksichtigt . 

^ Das Maximum moglicher aktiver Gerate ist 3 . Die maximale An- 
W zahl von in den Park-Modus schaltbaren Geraten ist 3. Die Ge- 
rate Gl, G2 und G3 senden Daten. Das Gerat G4 sendet keine 
15 Daten. 

Zu Beginn des Ausfuhrungsbeispiels befindet sich das Gerat G3 
im Park-Modus. Der Buchstabe A steht fur ein aktives Gerat. 
Der Buchstabe P steht fur ein geparktes Gerat. Die Buchsta- 

20 benfolge MUX steht fiir ein Gerat, das, obwohl es Daten sen- 
det, in den geparkten Modus geschaltet ist und darauf wartet, 
wieder in den aktiven Modus geschaltet zu werden. Der Buch- 
stabe M bezeichnet das Master-Gerat , welches die Steuerung 

^ durchf \ihrt . 

Fiir die Figur 2 ist weiter angenommen, dass eine Moglichkeit, 
ein Gerat in den aktiven Modus zu schalten, frei gehalten 
ist. 

30 Ausgehend voir Gerat G3, das Daten senden mochte und im ge- 
parkten Modus ist, wird das Gerat G3 in den aktiven Zustand 
geschaltet. 

Dafiir ist zum Beispiel an dieser Stelle das Gerat Gl in den 
35 geparkten Zustand zu schalten. Das Ger&t Gl sendet noch so 

lange Daten, bis der Datenspeicher gefullt ist. AnschlieSend 
wartet das Gerat Gl, bis es wieder in den aktiven Zustand ge- 
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schaltet wird. Dies ist der Pall, wenn eine andere Verbindung 
mit dem Datentransf er fertig ist. Ist dies der Pall, wird das 
Gerat Gl wieder in den aktiven Zustand geschaltet. 

Daftir ist zum Beispiel an dieser Stelle das Gerat G2 in den 
geparkten Zustand zu schalten. Das Gerat G2 sendet noch so 
lange Daten, bis der Datenspeicher gefiillt ist. Anschliefiend 
wartet das Gerat G2 , bis es wieder in den aktiven Zustand ge- 
schaltet wird. Dies ist der Fall, wenn eine andere Verbindung 
mit dem Datentransf er fertig ist. Ist dies der Pall, wird das 
Gerat G2 wieder in den aktiven Zustand geschaltet. 



Daftir ist zum Beispiel an dieser Stelle das Gerat G3 in den 
geparkten Zustand zu schalten. Das Gerat G3 sendet noch so 
15 lange Daten, bis der Datenspeicher gefiillt ist. AnschlieSend 
wartet das Gerat G3, bis es wieder in den aktiven Zustand ge- 
schaltet wird. Dies ist der Fall, wenn eine andere Verbindung 
mit dem Datentransf er fertig ist. Ist dies der Fall, wird das 
Gerat G3 wieder in den aktiven Zustand geschaltet. 



25 



Daftir ist zum Beispiel an dieser Stelle wieder das Gerat Gl 
in den geparkten Zustand zu schalten und der Vorgang setzt 
sich fort an der Stelle XI. MSglich ware auch gewesen, dass 
sich der Vorgang an der Stelle X2 fortsetzt. 
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Patentanspriiche 

1. Verfahren zum Betreiben eines Kurzstrecken-Funksende-/- 
Funkempfangssystems gemafi einem Kurzstreckenfunkkommunikati- 
5 onsstandard, insbesondere dem „Bluetooth«-Standard, nach dem 
bis zu einer auf Grund des Standards festgelegten oberen An- 
zahl Gerate mit einem Master-Gerat kommunizieren, dadurch 
gekennzeichnet, dass bei Vorhandensein einer Anzahl 
von Geraten oberhalb der durch den Standard festgelegten An- 
10 zahl von Geraten fur die Kommunikation mit dem Master-Gerat 
zumindest die gemaS dem Standard festgelegte obere Anzahl tt- 
bersteigende Anzahl an Geraten in einen Park-Modus geschaltet 
werden und dass fortlaufend nach einer vorgegebenen Strategie 
geparkte Gerate aktiv und aktive Gerate geparkt geschaltet 
15 werden. 

2. Verfahren nach Anspruch 1 dadurch gekennzeich- 
net, dass zusatzlich zur Mindestanzahl an in den Park-Modus 
geschalteten Geraten mindestens ein einziges weiteres Gerat 

20 in den Park-Modus geschaltet wird. 

3. Verfahren nach Anspruch 1 oder 2, dadurch gekenn- 
zeichnet, dass die vorgegebene Strategie auf Zeitscheiben 
basiert, die den einzelnen Geraten zyklisch zugewiesen wer- 
den. 

4. Verfahren nach Anspruch 1 oder 2, dadurch gekenn- 
zeichnet, dass die vorgegebene Strategie auf Priori tats- 
kriterien basiert, nach denen eine dynamisch veranderbare 

30 Reihenfolge der Gerate festgelegt wird, in der die geparkten 
Gerate in den Aktiv-Modus geschaltet werden. 



5. Verfahren nach Anspruch 4, dadurch gekennzeich- 
net, dass als Prioritatskriterium die Datenrate der einzel- 
35 nen Gerate herangezogen wird. 
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6. Verfahren nach Anspruch 1 oder 2, dadurch gekenn- 
zeichnet, dass die vorgegebene Strategie auf einer Mi- 
schung aus Zeitscheibenzuordnung und Beriicksichtigung von 
Priori tatskriterien basiert. 

5 

7. Master-Gerat zur Durchfuhrung des Verfahrens nach einem 
der Anspriiche 1 bis 6, dadurch gekennzeichnet, dass 
ein Geratemanager integriert ist, durch den die Steuerung von 
GerSten abwechselnd von einem Park-Modus in einen Aktiv-Modus 

10 und umgekehrt bewerkstelligt ist. 
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Zu s ammenf a s sung 

Verfahren zum Betreiben eines Kurzstrecken-Funksende-/- 
Funkempfangssystems gemaS einem Kurzstreckenfunkkommunikati- 
onsstandard und Master-Gerat zur Durchfuhrung des Verfahrens 

Es wird ein Verfahren zum Betreiben eines Kurzstrecken-Funk- 
sende-/-Funkempfangs systems gemafi einem Kurzstreckenfunkkom- 
munikationsstandard wie zum Beispiel den Bluetooth- Standard 
und zur Durchfuhrung des Verfahrens ein Master-Gerat vorge- 
schlagen, durch die eine gemaS dem Standard festgelegte maxi- 
male Anzahl von miteinander kommunizierbaren Geraten durch- 
brochen wird. Dies wird dadurch erreicht, dass bei Vorhanden- 
sein einer Anzahl von Geraten oberhalb der durch den Standard 
festgelegten Anzahl von Geraten fur die Kommunikation mit ei- 
nem Master-Gerat zumindest die gemaS dem Standard festgelegte 
obere Anzahl ubersteigende Anzahl an Geraten in einen Park- 
Modus geschaltet werden und dass fortlaufend nach einer vor- 
gegebenen Strategie geparkte Gerate aktiv und aktive Gerate 
geparkt geschaltet werden. 
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ZUSTAND GERATE: VDRRANR 
G1 G2 G3 G4 VORGANG 

a a p p - G3 sendet Daten 

- Entparken G3 



MUX 



p - Parken G1 , damit eine Aktiv- 

A A ' Position noch freigehalten, 

obwohl Datenfluss noch vor- 
hand en; 

- G1 sendet Daten, bis der 
MUX A A p Speicher gefullt ist; 

- Warten, bis ein Datentransfer 
zu Ende ist; 

- Entparken G1 ; 

a a a p - Parken G2, damit eine Aktiv- 

Position noch freigehalten, 
obwohl Datenfluss noch vor- 
han den; 

- G2 sendet Daten, bis der 
Speicher gefullt ist; 

- Warten, bis ein Datentransfer 
zu Ende ist; 

- Entparken G2; 

- Parken G3, damit eine 
Position freigehalten, ob- 
wohl ein Datenfluss vor- 
handen; 

- G3 sendet Daten, bis der 
Speicher gefullt ist; 

- Warten, bis ein Datentransfer 
zu Ende ist; 

- Entparken G3; 

- Fortsetzung an der Marke X1 
ode r X2; 
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